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This application is tlie National Stage of International Application No. 
PCT/EP02/00765, International Filing Date, January 25, 2002, which designated the 
5 United States of America, and which international application was published under 
PCT Article 21 (2) as WO Publication No. WO 03/063033 A2. 

BACKGROUND OF THE INVENTION 

The present invention relates to project management generally referred to as 
coordinating different tasks to be done or processed by different resources such as 
1 0 persons, departments or functions. 

SUMMARY OF THE INVENTION 

It is an object of the invention to provide tools or processes for Improved project 
management. The object is solved by the independent claims. Preferred embodiments 
are shown by the dependent claims. 

15 A project according to the present invention comprises a plurality of tasks and a 
plurality of resources available for handling, executing or otherwise processing one or 
more of the tasks. Each task and each resource is described by a data record 
comprising one or more characteristic features, properties, etc. thereof. A relationship 
identifier can be associated to each task representing its relationship to one or more of 

20 the resources. Accordingly or alternatively, a relationship identifier can be associated to 
each resource representing its relationship to one or more of the tasks. 

Task can be e.g. manual activities, creative work, administrative work, technical testing, 
etc. 

Resource can be e.g. an individual person, a group of persons (such as a department, 
25 a division, a project team, etc., a function within the company (such as a department 
head, a project manager, an extemal consultant, etc.), a competency (such as 
electrician, physicist, biologist, CAD-designer, etc.), or any other designation of 
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functional units within a project, including non-human resources such as machines and 
material. 

A relationship between task and resource can be e.g. an assignment (e.g. one 
resource is assigned to one task) or a non-assignment (e.g. one resource is NOT 
5 assigned to one task). In case of an assignment, the nature or kind of the assignment 
can be further specified e.g. by an assignment statement such as 'responsible' (i.e. this 
resource assigned to this task is also responsible for or the owner of this task) or 
'participant' (i.e. this resource assigned to this task but with no specific responsibility, 
dominance or ownership for this task). In case of a non-assignment, the relationship 
10 identifier can e.g. be left open, omitted or ignored and only 'positive' assignments will 
be considered. In one embodiment, a non-assignment is regarded as default, so that 
only positive assignments have to be specified. 

In a first embodiment of the invention, a processing unit receives the data records of 
the plurality of tasks and resources together with the respective relationship identifiers. 

15 For visually mapping the project, the processing unit then represents the plurality of 
tasks in a first dimension of a matrix and the plurality of resources in a second 
dimension of the matrix. Each relationship identifier is represented at the 
interconnection or point of intersection between each represented task and resource in 
the matrix, respectively. Thus, relationships between tasks and resources can be 

20 represented or illustrated efficiently allowing providing an improved project 
management. 

In one embodiment, only such relationship identifiers will be represented for (positive) 
assignments between resource(s) and task(s). Preferably, the relationship identifiers 
for (positive) assignments are represented as dots or the like. For better visualization, 
25 all relationship identifiers relating to one task might further be connected by a line or 
similar connection. Each different type of relationship might also be represented by a 
different type of relationship identifier, e.g. different sizes of dots or different 
geometrical figures. 

In another embodiment, the tasks are arranged in accordance to defined relationships 
30 between the tasks such as temporal relationships and/or priorities. Preferably, the 
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tasks are arranged inlemporal order so that tasks to be started earlier will be 
represented first in the matrix dimension. In otiier words, successive tasks will be 
represented in successive order along the first matrix dimension. This arrangement can 
significantly improve comprehensibility of the matrix. 

5 In another embodiment, dependencies between tasks are further indicated in the 
matrix. Preferably, successive and dependent tasks are indicated e.g. by a pointer or 
an arrow pointing from one or more former tasks to the successive and dependent 
task(s). This indication of dependencies in particular in combination with an adequate 
arrangement of the tasks (preferably in successive order). In one embodiment, such 
10 dependencies are indicated using adequate pointers (preferably arrows), whereby the 
pointers are directed between dedicated or selected resources assigned to the 
respective tasks. Preferably, the pointers are directed between such resources 
assigned as being responsible or otherwise superior to the respective tasks. 

In a further embodiment, a plurality of resources is grouped together and represented 
15 only as one resource group. If one member of the resource group has a certain 
relationship identifier with one task, the resource group represents that relationship 
identifier for that task. In case that the resource group has plural different relationship 
identifiers with one task, the resource group preferably represents only one relationship 
identifier for that task according to a predefined selection criteria. Selection criteria can 
20 be e.g. priority (preferably highest priority) or responsibility of an assignment (preferably 
highest responsibility). Preferably, resource groups are represented differently than 
other resources in order to clearly indicate the grouped nature. Adequate tools might 
be provided for transforming plural resources into one resource group and vice versa. 

Accordingly or alternatively, a plurality of tasks can be grouped together and 
25 represented only as one task group. If one member of the task group has a certain 
relationship identifier with one resource, the task group represents that relationship 
identifier for that resource. In case that the task group has plural different relationship 
identifiers with one resource, the task group preferably represents only one relationship 
identifier for that resource according to a predefined selection criteria. Selection criteria 
30 can be e.g. priority (preferably highest priority) or responsibility of an assignment 
(preferably highest responsibility). Preferably, task groups are represented differently 
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than other tasks in order to clearly indicate the grouped nature. Adequate tools might 
be provided for transforming plural tasks into one task group and vice versa. 

In a further preferred embodiment, the processing unit further analyses the matrix and 
provides a plausibility check. Potential failures detected by this plausibility check are 
5 preferably indicated directly in the matrix e.g. by modifying the current representation (s) 
associated with each potential failure. Such modification can be e.g. varying color or 
shape etc. In one embodiment wherein the tasks are arranged in temporal order and 
dependencies between tasks are indicated, dependencies directing in reverse temporal 
order (e.g. one task is dependent on results of another task, but the other task 
1 0 starts/ends later) can be candidates for potential failures. By arranging the tasks with 
increasing start date and indicating dependencies e.g. by arrows, arrows pointing 
'backwards' in the sequence of successive tasks are likely to be potential failures. 

Another plausibility check can be for detecting 'isolated' tasks i.e. tasks having no 
successive task being dependent thereon or tasks having no dependency to a 
15 precedent task. In an example when indicating dependencies e.g. by arrows, tasks 
without arrows or tasks either only receiving or 'emitting' an arrow can represent such 
'isolated' tasks. 

A further plausibility check can be for detecting 'milestone-ignoring' task dependencies, 
i.e. a dependency of a later task to a former task when a milestone is in-between. A 
20 milestone in that sense means a task, which constitutes a control point within the 
project and is typically attributed a defined date. 

In a further embodiment, the processing unit provides an indication for which tasks are 
milestones. Preferably, a milestone would be visible by a readily visible border around 
the entire task, or by a gray or colored shading which accentuates this task in a visual 
25 manner. 

In another embodiment, the processing unit further provides an indication for the state 
of one or more of the tasks. Different states can be e.g. 'not started', 'pending', 
'finished', 'cancelled', 'postponed', 'skipped', 'due', 'overdue', 'in-time', 'experiencing 
difficulties', 'running as foreseen', 'on schedule', or 'over time'. Preferably, different 
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states are indicated in different colors, e.g. 'green = in-time', 'yeHow = experiencing 
difficulties', 'red = over time'. 

In one embodiment, the tasks are represented by parallel lines in the first matrix 
dimension, and the resources are represented by parallel lines in the second matrix 
5 dimension. The first matrix dimension preferably is substantially perpendicular to the 
second matrix dimension. 

In a further embodiment, two or more different but somehow related projects are 
provided in a joint representation, wherein preferably the first matrix dimensions of all 
projects are represented substantially parallel to each other and, accordingly, the 

10 second matrix dimensions of all projects are also represented substantially parallel to 
each other. In this case, one of the matrixes (preferably the one on the right hand side 
of the diagram) may be mirrored such that the matrixes appear back-to-back. 
Dependencies between tasks of different projects can be indicated in the joint matrix 
substantially in accordance with the above said. Preferably, such dependencies are 

15 indicated using adequate pointers (preferably arrows). 

In yet another embodiment of the invention, the processing unit receives information 
about an actually provided visual mapping of the project, and the processing unit 
derives therefrom the data records of the plurality of tasks and resources together with 
the respective relationship identifiers. For that purpose, the processing unit analyses 

20 the representations of the plurality of tasks in the first dimension of the matrix and the 
plurality of resources in the second dimension of the matrix together with the 
representation of each relationship identifier at the interconnection between each 
represented task and resource in the matrix, respectively. This is in particular useful in 
case data records have been modified in the represented matrix, e.g. by user 

25 intervention or under influence of a different tool or software. However, even entirely 
new matrix representations (e.g. provided or designed by users) can thus be 
'transformed' into machine-processable data records. It is clear that any additional 
information e.g. as introduced in the above embodiment, such as relationship types or 
dependencies, can thus be 'transformed' accordingly into the data records. 

30 The invention can be partly or entirely embodied or supported by one or more suitable 
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software programs, which can be stored on or otherwise provided by any kind of data 
carrier, and which might be executed in or by any suitable data processing unit. 

BRIEF DESCRIPTION OF THE DRAWINGS 

Other objects and many of the attendant advantages of the present Invention will be 
5 readily appreciated and become better understood by reference to the following 
detailed description when considering in connection with the accompanied drawings. 
Features that are substantially or functionally equal or similar will be referred to with the 
same reference sign(s). 

Figs. 1 A-D illustrate principles of the invention. 

10 Figs. 2A and B illustrate in detail a preferred embodiment of the invention. 

DETAILED DESCRIPTION OF THE INVENTION 

Fig. 1 illustraites the invention in an example of a project comprised of five tasks 
TASK01-TASK05 to be handled by seven resources RESOURCE01 -RESOURCED?. 
Each task and each resource is described by a respective data record including 
1 5 relationship identifiers representing the assignments of resources to respective tasks. 

A processing unit (not shown) receives the data records and represents the tasks 
TASK01-TASK05 in a first dinriension of a matrix and the resources RESOURCE01- 
RESOURCE07 in a second dimension of the matrix. In the example of Fig. 1 A, the first 
dimension is the x-axis of a 2-dimensional matrix and the second dimension is the y- 
20 axis thereof . Each relationship identifier is represented at the interconnection between 
task and resource in the matrix. In the example of Fig. 1 A, a (positive) assignment of a 
resource to a respective task is represented by a dot, while a non-assignment (i.e. the 
resource is not assigned to this task) is considered as default and not further indicated. 

In the example of Fig. 1A, task TASK01 is to be processed by assigned resources 
25 RESOURCE01 and RESOURCE05, task TASK02 is to be processed by assigned 
resources RESOURCE02, RESOURCE03, arid RESOURCED?, etc. 

Fig. 1B shows an alternative representation for the project example shown in Fig. 1A. 
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First difference is that the type of assignment is further specified by indicating with a 
bigger dot the assignment of that resource responsible for that task and with a smaller 
dot the simple assignment of that resource to that task without having the responsibility 
thereof. Second difference is that all relationship identifiers relating to one task are 
5 connected by a thick line for better visualization. 

Third difference is that dependencies between tasks are further indicated by arrows in 
the matrix. In the example of Fig. IB, the execution of task TASK02 requires results 
from task TASK01. This is indicated by an arrow from resource RESOURCE05 
assigned as responsible for task TASK01 to resource RESOURCE03 assigned as 
10 responsible for task TASK02. Accordingly, results from task TASK02 are to be reported 
to resource RESOURCE07 assigned as responsible for tasks TASK03 and TASK04. 
Eventually, results from task TASK05 are also to be reported to resource 
RESOURCED? assigned as responsible for task TASK04. 

In order to improve comprehensibility of the matrix, the tasks are arranged along the y- 
15 axis in successive order indicating that task TASK01 is to be started or processed 
before task TASK02, task TASK02 is to be started or processed before task TASK03, 
etc- 

The processing unit might further analyze the matrix and provide a plausibility check for 
potential failures. In the example of Fig. 1B, it is detected that task TASK04 is 
20 dependent on results of task TASK05, but task TASK05 starts/ends later than task 
TASK04. Such arrow pointing 'backwards* is likely to be a potential failure and will 
therefore be indicated by a dotted or otherwise accentuated fine. A user can then 
further analyze the dependency between tasks TASK04 and TASK05 and might 
correct that (e.g. that task TASK05 becomes dependent on results of task TASK04). 

25 Fig. 1C illustrates an embodiment for the example of Fig. 18, wherein resource 
RESOURCED? represents a group of individual resources RESOURCED7A- 
RESOURCED7D, and task TASKD5 represents a group of individual tasks TASKD5A- 
TASKD5D. While Fig, 1 B shows the groups as such, the illustration of Fig. 1C depicts 
all individual tasks and resources of the groups. 



-7- 



Fig. 1D shows an example wherein two related projects are provided in a joint 
representation. Dependencies between tasks of the different projects are indicated by 
arrows. 

While Figs. 1 illustrated basic examples, a more detailed example shall now be 
5 considered in conjunction with Figs. 2A and 2B. The project mapping diagram 
presented here shall now be referred to as Matrix. 

Data needed for the elaboration of the Matrix are preferably kept in a database or a file 
containing information concerning the project, as shown in Table A below. Examples 
are provided for data formats Microsoft Project (.mpp) and Primavera Project Planner 
10 for the Enterprise (P3e). 



Data field in 
database or file 


Data Type 


Examples for mapping 
(.mpp and P3e) 


Explanation 


Unique identifier for 
task 


numerical 


Unique ID 
task_ID 


Unique task ID number 


WBS Code 


Hierarchical 
numbering 
(.mpp) or 
alphanumerical 
(P3e) 


WBS or Outline.no. 
wbs.id 


Work Breakdown Structure 
Code 


Task name 


alphanumerical 


Name (Task table) 
task_name 


Name of the task 


Status 


alphanumerical 


Status or other 
status_code or other 


Current status of task 



-8- 



ft 



Predecessors 


numerical 


Unique ID Predecessors 


List of all tasks of which 
the current task is 
dependent (has a 
predecessor-successor 
dependency relation). 
(Successor infonnation is 

pali^iildtoH out f\i 

predecessor information 
and therefore redundant) 


IVlllCOlUIIC 




iviiicolUi It? 

taskjype 


Tack ic a miloctAnct if 

value = 1 ortask_type = 
milestone 


Resource 


alphanumerical 


Resources 
taskrsrc 


Person participating in 
task 


Department 


alphanumerical 


Resource group ^ 
OBS, resource codes 


Department participating 
in task 


Role 


alphanumerical 


User-defined fields 
role 


Competence of person in 
the context of the project 


Resnonsible 

1 IwwI^V/l Iwl vlw 


RssDonsible 
person 


First resource 

1 liwi ICwWIIww 

primary resource 


Resource deoartment or 
role responsible for the 
elaboration of the task 



Table A 



Using the data contained in the database or file, the representation according to the 
present invention can be generated as the Matrix of the project, as illustrated in Figs. 
2A-B. The Matrix lists the different tasks of the project from top to bottom, and with 
several alphanumeric fields (columns) on its left side. 



Each of the data fields in Table A needed for the Matrix will now be described in detail. 



The first three fields are used to determine the text in the left-hand side of the Matrix 
(see Figs. 2A-B) while the other six fields determine how the right hand side of the 
Matrix (see Figs. 2A-B) will be drawn graphically. 

Unique ID (Unique ID): The identification number ID is a number issued automatically 
5 during the planning of the project by the user. In the case of the Unique ID number, this 
number never changes, even when the task order is changed by the user. Therefore^ 
Unique ID can be used as a key to keep track of tasks even when their order is 
changed. The Unique ID is preferably not displayed in the Matrix. 

WBS-Code (WBS): The work breakdown structure (WBS) is a classic technique of 
1 0 project management with which the overall objective of a project is divided into several 
manageable tasks. The WBS-Code is a hierarchic code: a task with a number 2 (see 
Figs 2A), for instance, can have several subtasks 2.1, 2.2, 2.3, etc. (see Fig. 2B). 
Subtasks can be further divided into subtasks such as 2.1.1, 2.1.2, etc. The WBS- 
Code for a task is to be displayed in the first column of the Matrix (note that tasks and 
15 subtasks have a different length in their WBS-Code due to the hierarchic 
representation, but the unique ID-Number of any specific task will always be only one 
number. This number will remain unchanged when the task is made to a subtask or 
summary task or even when its order within the project is changed). The WBS-Code 
will be of further importance for the functionality of showing and hiding the subtasks of 
20 a summary task (see below). 

Name (Name): The name of the task is the second column to be displayed on the left 
side of the Matrix. It simply specifies whait is to be done in the task. 

The Matrix therefore begins with two or more alphanumeric columns. Adjacent to these 
columns, columns representing the resources of the project are introduced, as are dots 
25 and arrows to illustrate the communication flow in the project. The following data fields 
determine the graphical representation of this right hand side of the Matrix. 

Using the data contained in the database or file, many different types of Matrixes can 
be drawn by using resources, departments, roles, or any other attribute of the actors in 
the project to define the right hand side of the Matrix. Each actor of the project is 
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represented by a column on the right hand side of the Matrix. The following 
explanations will concentrate on the first kind of Matrix using resources as column 
titles. All other Matrix types are elaborated In the same manner and will be described 
aften/vards. 

5 Once the columns have been defined, dots and arrows can be added to illustrate the 
assignments and dependencies in the project. The following fields provide the 
necessary information to do so. 

Resources: All resources active in the task are marked by a dot. 

Responsible: The responsible resource in each task is marked with a large black dot. 
10 When there is more than one participating resource in a task, all participating and 
responsible resources may be connected with a black line. 

Arrows are drawn between the responsible resource of a preceding task to the 
responsible of a subsequent task. The horizontal position of an arrow is thus 
determined by the information contained in each task. All arrows from preceding tasks 
15 are therefore to go to the large dot representing the responsible, and arrows going to 
succeeding tasks shall originate from this large dot (this is the case when the 
"Predecessors" fields of other tasks point to the current task). 

Status: The user enters the current status of each task into this field. The processing 
unit of the system interprets the data of this field to display an intuitively 
20 comprehensible dot of a corresponding color, e.g. 'green = in-time', 'y^'low = 
experiencing difficulties', 'red = over time'. 

Milestone (Milestone): This Boolean field is active when a task is a so-called milestone 
of a project. In this case, the task preferably appears in gray shading and with a border 
around it. Examples for milestones are Tasks 3 and 16 in Figs. 2A-B. The text of the 
25 milestone preferably appears in bold print. 

Summary tasks: Summary tasks regroup several subtasks to a larger task. This is 
important for a project manager in order to mask unnecessary detail, e.g. when he is 
trying to get an overview over a larger project. The notion of summary tasks and 



-11 - 



subtasks is closely related to that of WBS (work breakdown structure), with which a 
project is first broken down into larger tasks (sometinnes called work sections) and then 
further into smaller tasks (see chapter on "WBS"). 

In one embodiment, the user has the possibility to hide and show subtasks of a project, 
5 e.g. in order to view particular parts of a project in greater detail, while seeing only the 
summary tasks of parts which are of less importance. In this embodiment, summary 
tasks have a little box displayed next to their name so the user understands that these 
particular tasks contain subtasks. When the user clicks on one of these boxes with the 
sign (see Task 2 in Fig. 2A), the sign changes to "-" and the subtasks are shown 
10 (see Task 2 in Fig. 28). When the user clicks on one of the boxes to open a summary 
task and show its subtasks, the arrows and dots in the Matrix change. Any resource 
participating in one of the subtasks (responsible or not) now appears as a dot in the 
collapsed summary task, i.e. when the subtasks are hidden. In a further embodiment, a 
specific field is defined for the responsible resource of a summary task. Whichever 
15 resource is responsible for the summary task preferably appears as a large dot or 
whatever other graphical indicator niay be found appropriate. 

Since a summary task is in itself not an independent task but only an aggregation of 
several subtasks, the communication arrows preferably no longer go through the 
summary task when its subtasks are visible. However, direct communication arrows 
20 between summary tasks could exist if the user defined them explicitly. When 
communication arrows are defined directly with summary tasks, their communication 
arrows preferably still go out of the summary task even when subtasks become visible. 

Since subtasks can be under the responsibility of several different resources, the 
responsible of each summary task needs to be defined separately. A summary task 
25 can even be under the responsibility of a resource that is not responsible for any of its 
subtasks, e.g. when a resource is responsible as a coordinator for the summary task. 
When the subtasks of a summary task are shown, the Responsible System Function of 
the summary task is preferably marked with a large circle or another graphical indicator 
found appropriate rather than a large dot to prevent misunderstandings. 

30 When the user clicks on the box of a summary ^ask to expand it, the communication 
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arrows going to or originating from subtasks preferably no longer go to the summary 
task, but directly to the subtasks and their responsible functions. 

The following tables Table 1 and Table 2 explain in detail the tasks of the Figs. 2A and 
2B, whereby Table 1 corresponds to Fig. 2A and Table 2 corresponds to Fig. 2B. The 
WBS-numbers link the respective tables and figures, so that e.g. the WBS-number 1 in 
Fig. 2A corresponds to the task "SWOT analysis" with the infomnation "Strengths and 
weaknesses of the company " in Table 1 . 



WBS 


Task 


Information 


0 


MS 0: Kick-Off Decision 


Go! 


1 


owvj 1 analysis 


oirenyins ariQ W6aKneso6o ui ine cuinpcii ly 


2 


UGTiniiion Oi pressni Dusineso iieiuo 
of the company 


Llol OT DUoin6oo TieiQS 


o 


iVio 1. vvnicn ciiiq iiow riiciiiy 
business fields should the company 
pursue? 


VV MIUI 1 Lf 1 "OCl H Cll IWl |JWlC7IIUCII IhJLIOll ICOO IIC7IIJO- 

exist? Definition of future market strategy. 


4 


Appointment of chairmen of each 
strategy circle 


Chairman of each strategy circle 


5 


Call for participation in strategy 
circles 


Complete list of members for each strategy 
circle 


6 


Strategy circle meetings 


List of opportunities 


7 


Market identification for business 
field 


List of markets served and ignored 


8 


Analysis of refused offers 


List of refused offers including reasons for 
refusal. 
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9 


Investigation of potential markets 
withjn business field 


List of potential markets in Spain and abroad 


10 


Analysis of competition 


List of universities, institutes and companies 
liable to serve similar customer needs 


11 


Identification of missing 
competencies and resources w/ 
regard to targeted markets and 
customers 


List of missing competencies and resources 
and proposal for cooperation or otiier solutions 


12 


Analysis of earnings potential 
(profitability) by groups of customers 


Information concering surplus creation, 
possible pricing policy. 


13 


New business opportunities 


List of other business fields that have 
appeared due to the in-depth investigation of 
the market 


14 


Analysis of possibilities to protect 
knowledge in the business field 


Industrial property protection suggestions 

1 


15 


Drafting of final report for business 
field 


Business field report 


16 

Table 


MS 2: Decision on future action 


Are any important business fields not 
covered? List of served, missed, potential 
markets and refused offers. Analysis of 
competition, missing competencies, 
suggestion for cooperations. 
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WBS 


Task 


Information 


0 


MS 0: Kick-Off Decision 


Go! 


1 


SWOT analysis 


Strengths and weaknesses 


o 
2 


u6Tiniiion or preseni Dusiness Tieias 
of the company 


LIST OT Dusiness Tieius 


2.1 


Brainstorming event to identify new 
business fields 


New potential business fields 


2.2 


Delimitation of business fields 


Exact definition of each business field 


2.3 


ueTinition ot possiDie MarKeting 
strategies 


ocenarios ot aiTTereni marKeiing sTraTegies 


2.4 


Definition of terms of reference for 
strategy circles 


Terms of reference, goals and composition of 

S 


3 


MS 1 : Which and how many 
Dusiness iieias snouia ine company 
pursue? 


Which present and potential business fields 
exiSi r ueTiniiion ot Tuiure marKei siraTegy. 


4 


Appotnimeni ot cnairmen ot eacn 
strategy circle 


onairman ot eacn STraiegy circie 


5 


Call for participation in strategy 
circles 


Complete list of members for each strategy 
circle 


6 


Strategy circle meetings 


List of opportunities 


7 


Market identification for business 
field 


List of markets iserved and ionored 

k.1 w L w 1 II Idl rVw Iw wwl V w VI dl IVi Igl Iwl WVJ 


8 


Analysis of refused offers 


List of refused offers including reasons for 
refusal. 
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# 



9 


Investigation of potential markets 
within business field 


List of potential markets in Spain and abroad 


10 


Analysis of competition 


List of universities, institutes and companies 
liable to serve similar customer needs 


11 


Identification of missing 

regard to targeted markets and 
customers 


List of missing competencies and resources 
and nrnnn^fll for cooDeration or other solutions 


12 


Analysis of earnings potential 
(profitability) by groups of customers 


Information concering surplus creation, 
possible pricing policy. 


1 o 




1 l^t of othpr hii^inp^^ fiplds that have 
appeared due to the in-depth investigation of 
the market 


14 


Analysis of possibilities to protect 
knowledge in the business field 


Industrial property protection suggestions 


15 


Drafting of final report for business 
field 


Business field report 


16 


MS 2: Decision on future action 


Are any important business fields not 
covered? List of served, missed, potential 
markets and refused offers. Analysis of 
competition, missing competencies, 
suggestion for cooperations. 



Table 2 



What is claimed is: 
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1 . A system for visually mapping a project comprising a plurality of tasks and a 



plurality of resources, each resource being available for handling, executing or 
othenA^ise processing one or more of the tasks, wherein a relationship between a 
respective task and a respective resource is described by a respective 
relationship identifier, the system comprising: 

a processing unit adapted for receiving data records of the plurality of tasks and 
resources together with the respective relationship identifiers, and for 
representing the plurality of tasks in a first dimension of a matrix and the plurality 
of resources in a second dimension of the matrix, wherein each relationship 
identifier is represented at the interconnection or point of intersection between 
represented task and resource corresponding to that relationship identifier. 

2. The system of claim 1 , wherein each task and each resource is described by a 
data record comprising one or more characteristic features or properties thereof, 
and at least one of the relationship identifiers is associated a corresponding data 
record of the task or the resource. 

3. The system of claim 1 , wherein at least one of the resources Is one of an 
individual person, a group of persons, a department, a function, a competency, or 
any other type of entity found appropriate to circumscribe an actor of the projfe'c!? 



4. The system according to claim 1 , wherein at least one of the relationships 
between task and resource is an assignment, so that the resource is assigned to 
the task, or a non-assignment, so that the resource is not assigned to the task. 

5. The system according to claim 1 , wherein the processing unit is further adapted 
for specifying a type, nature or kind of the relationship. 

6. The system according to claim 1 , wherein the processing unit is further adapted 
for representing each different type, nature or kind of the relationship by a 
different type of relationship identifier. 
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7. The system according to claim 1 , wlierein tine processing unit is further adapted 
for representing at least one of the relationship identifiers as a dot or similar 
geometrical figure. 

8. The system according to claim i , wherein the processing unit is further adapted 
for representing all relationship identifiers relating to one task by a connected line 
or similar connection. 

9. The system according to claim 1 , wherein the processing unit is further adapted 
for arranging the tasks in accordance to defined relationships between the tasks 
such at least one of temporal relationships and priorities. 

10. The system according to claim 1 , wherein the processing unit is further adapted 
for indicating dependencies between tasks. 

11. The system according to claim 1 0, wherein the processing unit is further adapted 
for indicating dependencies between tasks by using pointers or arrows. 

12. The system according to claim 1 , wherein the processing unit is further adapted 
for grouping a plurality of the resources together and representing those grouped 
resources as one resource group. 

1 3. The system according to claim 1 , wherein the processing unit is further adapted 
for grouping a plurality of the tasks together and representing those grouped 
tasks as one task group. 

14. The system according to claim 1 , wherein the processing unit is further adapted 
for analyzing the matrix and providing a plausibility check for at least one of 
detecting and indicating potential failures. 

15. The system according to claim 1 , wherein the processing unit is further adapted 
for providing an indication for the state of one or more of the tasks. 

16. The system according to claim 1 , wherein the processing unit is further adapted 
for representing the tasks by parallel lines in the first matrix dimension and the 
resources by parallel lines in the second matrix dimension. 
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17. The system according to claim 16, wherein the first matrix dimension is 
substantially perpendicular to the second matrix dimension. 

1 8. The system according to claim 1 , wherein the processing unit is further adapted 
for providing two or more different projects in a joint representation, wherein the 
first and second matrix dimensions are each represented substantially parallel to 
each other. 

19. A method for visually mapping a project comprising a plurality of tasks and a 
plurality of resources, each resource being available for handling, executing or 
othenwise processing one or more of the tasks, wherein a relationship between a 
respective task and a respective resource is described by a respective 
relationship identifier, the method comprising: 

receiving data records of the plurality of tasks and resources together with the 
respective relationship identifiers, 

representing the plurality of tasks in a first dimension of a matrix, 

representing the plurality of resources in a second dimension of the matrix, and 

representing each relationship identifier at the interconnection or point of 
intersection between represented task and resource corresponding to that 
relationship identifier. 

20. The method of claim 19, further comprising one or more of the following: 
specifying a type, nature or kind of the relationship, 

representing each different type, nature or kind of the relationship by a different 
type of relationship identifier, 

representing at least one of the relationship identifiers as a dot or similar 
geometrical figure, 

representing all relationship identifiers relating to one task by a connected line or 
similar connection, 
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arranging the tasks in accordance to defined relationships between the tasks 
such as at least one of temporal relationships and priorities, 

indicating dependencies between tasks preferably using pointers or arrows, 

grouping a plurality of the resources together and representing those grouped 
resources as one resource group, 

grouping a plurality of the tasks together and representing those grouped tasks as 
one task group, 

analyzing the matrix and providing a plausibility check for at least one of detecting 
and indicating potential failures, 

providing an indication for the state of one or more of the tasks, 

representing the tasks by parallel lines in the first matrix dimension and the 
resources by parallel lines in the second matrix dimension, wherein the first matrix 
dimension is preferably substantially perpendicular to the second matrix 
dimension, 

providing two or more different projects in a joint representation, wherein the first 
and second matrix dimensions are each represented substantially parallel to each 
other. 

A method comprising: 

receiving information about a provided visual mapping of a project comprising a 
plurality of tasks and a plurality of resources, each resource being available for 
handling, executing or othenwise processing one or more of the tasks, wherein a 
relationship between a respective task and a respective resource is described by 
a respective relationship identifier, wherein the plurality of tasks are represented 
in a first dimension of a matrix, the plurality of resourciBS are represented in a 
second dimension of the matrix, and each relationship identifier are represented 
at the interconnection or point of intersection between represented task and 
resource corresponding to that relationship identifier, and 
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0- 

deriving from the received information data records of tlie plurality of tasks and 
resources together with the respective relationship identifiers. 

22. The method of claim 21 , further comprising: 

analyzing the representations of the plurality of tasks in the first dimension of the 
matrix and the plurality of resources in the second dimension of the matrix 
together with the representation of each relationship identifier at the 
interconnection between each represented task and resource in the matrix, 
respectively. 

23. A software program or product, preferably stored on a data carrier, for executing 
the method of claim 19, when run on a data processing system such as a 
computer. 
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